The cost of developing a complex computer system can be very high. This high cost is attributable to many factors. It can take many man-years of effort to design a complex computer system, and the cost of the design effort is typically only a small fraction of the overall cost of the development effort. Indeed, the cost to develop, test, and document the computer code for such complex computer systems can be many times the cost of the design effort. Although many development tools are available to assist a software developer, development costs are still high.
For many years, "code reuse" and "code sharing" have been promoted as a way to lower the development costs. Typical techniques for "code reuse" and "code sharing" have relied upon object-oriented techniques that make various objects available for reuse. However, such typical techniques have serious drawbacks. Many objects that are made available for reuse provide extensive functionality so that they can be reused by many different types of computer systems that use different functionality of the objects. For example, an object that provides word processing functionality can be very complex and large. Such an object may be reused by a word processing program and by a dialog box manager. Although such an object may provide sophisticated word processing functionality, such sophisticated functionality may not be needed by certain applications that only need rudimentary word processing functionality (e.g., a dialog box manager). Thus, if such an application were to use such word processing object, much of the object's functionality would be unused, and the application would, as a result, be much larger than necessary.
Techniques have been developed that allow a programmer to combine objects with limited functionality into a combined object that has the functionality of its constituent objects. Two such techniques are referred to as "containment" and "aggregation." "Containment" refers to the complete encapsulation of one object (i.e., a containee object) by another object (i.e., container object). Complete encapsulation means that an object external to the container object cannot directly access any of the functionality of the containee object. Rather, the container object receives every request from the external object to access the functionality of the combined object, and the container object may invoke the functionality of the containee object to help provide the requested functionality. "Aggregation" refers to the combining of objects into an aggregated object so that the functionality of one object (i.e., an enclosed object) is exposed directly by that object or indirectly by another object (i.e., enclosing object), and vice versa. Aggregation means that an object external to the aggregate object can directly access functionality of the aggregate object through either the enclosing object or the enclosed object. With both these techniques, an external object views the combined object as a single object and is unaware of the combination. The concepts of the "containment" and "aggregation" are described in Inside OLE 2 written by Kraig Brockschmidt and published by Microsoft Press in 1994. "Aggregation" is further described in U.S. Pat. No. 5,745,764, which issued on Apr. 28, 1998, and is hereby incorporated by reference.
The techniques of containment and aggregation have limitations. With containment, the container object needs to be developed with full knowledge of the functionality of the containee object. Thus, the container object cannot be developed independently of the containee object. With aggregation, internal references between the enclosing object and enclosed object have special "Query Interface" and reference accounting rules, which adds complexity and confusion. Moreover, both techniques leave the developer to instantiate and manage the containee and enclosed objects.
Another technique for facilitating code reuse and code sharing is the use of a part-whole hierarchy where each object is responsible for managing the objects immediately below it in the hierarchy. However, when using a part-whole hierarchy, the code for instantiating and managing the sub-objects is placed with the code that provides the functionality of the combined object, which a developer needs to implement for each combined object.
It would be desirable to have a new technique for code reuse and sharing that does not have the drawbacks of these current techniques.